IAM Identity Center ユーザー向けにS3静的サイトを提供する【Verified Access】
2024.09.05本ブログでは IAM Identity Center ユーザー向けに「S3でホストしている静的サイト」を共有 してみます。
モチベーションは「AWS利用者に向けて情報を共有したい」です。 例えばAWS利用のルールやガイドラインなどです。 他のドキュメントプラットフォーム(Confluence, Backlog wikiなど) でも問題ありませんが、 できればAWSに関わる人に直接紐づけて共有したいなと思いました。
調べていたところ、以下ブログを拝見しました。
「これらを組み合わせればできるのでは？」と思い、実際にやってみました。
構成概要
以下ざっくりとした構成図です。
「ALB → S3部分」と「Verified Access → ALB 部分」を、 もう少し詳しく説明します。
ALB → S3 部分
『静的サイト(S3)にプライベートアクセスできる環境』を作ります。 インターナルALBを作成します。 インターナルALBのターゲットとしてS3エンドポイント( インターフェイス型 )を指定します。
なお、この部分の構築手順は以下ブログとほぼ同じです。
Verified Access → ALB 部分
次に『認証されたユーザーのみ、この環境へアクセスできる仕組み』を作ります。
主要サービスは AWS Verified Access です。 Verified Access はアプリケーションへ安全にリモートアクセスしたいときに役立つサービスです。 ここでいうアプリケーションとは、 プライベートにあるロードバランサーやネットワークインターフェイスです。
サイトへのアクセス許可は、本ブログでは 「IAM Identity Center で管理しているユーザー全て」に与えます。 これは絞ることも可能です。
ユーザーはVerified Accessのエンドポイントへアクセスします。 IAM Identity Center の認証を経て、ALB(=S3静的サイト)へアクセスします。
構築する(ALB → S3部分)
まずは ALB → S3 部分を構築します。 先ほども言ったとおり すでにある quiver さんのブログ とほぼ同じです。
VPC, サブネット
VPCを作成します。 このVPCに今後 ALB を配置します。
またプライベートサブネットも作成しておきます。 最低 2AZ分、つまり2つのサブネットを用意します。 ※ ALB作成時には少なくとも 2AZ のサブネットを選択する必要があるため。
セキュリティグループ
以下3つのセキュリティグループ(以降SG)を事前に作成しておきます。
| 用途 | インバウンドルール | アウトバウンドルール |
|---|---|---|
| Verified Access用 | なし | 全て許可 |
| ALB用 | Verified Access用SGからの HTTPS(443)を許可 | 全て許可 |
| VPCエンドポイント用 | ALB用SGからの HTTP(80),HTTPS(443)を許可 | 全て許可 |
S3インターフェイス型VPCエンドポイント
ALBのターゲットとなるS3インターフェイス型VPCエンドポイントを作成します。
今回は1つのAZのみ指定します。IPアドレスを直打ちで設定します。
作成時に先ほど作成したVPCエンドポイント用SGを設定します。
VPCエンドポイントのID(vpce-xxx)をメモしておきます。後ほどのバケットポリシーで必要です。
S3バケット
アクセスさせるドメインと同じ名前のS3バケットを作成します。 後ほどのアクセステスト用に index.html を入れておきます。
バケットポリシーにて、先程のVPCエンドポイント(vpce-xxx)からの GetObject を許可しておきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Access-to-specific-VPCE-only",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::${S3バケット名}",
"arn:aws:s3:::${S3バケット名}/*"
],
"Condition": {
"StringEquals": {
"aws:SourceVpce": "${VPCエンドポイントID}"
}
}
}
]
}
ACM証明書
アクセスさせるドメインのSSL/TLS証明書を発行しておきます。
ALBターゲットグループ
以下設定値のターゲットグループを作成します。
- ターゲットタイプ: IPアドレス
- ターゲットグループのプロトコル: HTTPS
- ヘルスチェックのプロトコル: HTTP
- ヘルスチェックのパス:
/ - ヘルスチェックの成功コード: 307
- ターゲットのIPアドレス: (先程のS3エンドポイントのIPアドレス)
ALB
内部向けのALBを作成します。
- セキュリティグループ: 先ほど作成したALB用SG
- リスナーのプロトコル: HTTPS
- リスナーのデフォルトアクション: 先ほど作成したターゲットグループに転送
- リスナーの証明書: 先ほど作成したACM証明書
構築する(Verified Access → ALB部分)
次に Verified Access 部分の構築です。
以下順番で作成していきます。
- Verified Access 信頼プロバイダー
- Verified Access インスタンス
- Verified Access グループ、グループポリシー
- Verified Access エンドポイント
- Route 53 CNAMEレコード
なお、Verified Access の各要素については以下ブログが参考になります。
信頼プロバイダー
Verified Access 信頼プロバイダーを作成します。 信頼プロバイダータイプは IAM Identity Center を選択しましょう。
インスタンス
Verified Access インスタンスを作成します。 その際に、先程作成した信頼プロバイダーを選択します。
グループ, グループポリシー
Verified Access グループを作成します。 先程の作成したインスタンスを指定します。
ポリシー部分には以下を記載します。 これは信頼プロバイダーの認証に成功したら無条件に接続できる内容です。
permit(principal,action,resource)
when {
true
};
エンドポイント
Verified Access エンドポイントを作成します。 先ほど作成したグループを指定します。
エンドポイントの詳細は以下のように指定します。
- プロトコル: HTTPS
- アタッチメントタイプ〜サブネット: ALBの情報
- セキュリティグループ: Verified Access 用SG
- エンドポイントドメインプレフィクス: 適当に記載(endpointなど)
アプリケーションの詳細には 接続先ドメインおよび、 そのACM証明書を選択します。
作成後、ステータスが Active になれば OKです。 エンドポイントドメインの値をメモしておきましょう。
Route 53 CNAMEレコード
CNAMEレコードに アプリケーションドメイン → エンドポイントドメイン の内容を登録します。
接続確認
実際にアプリケーションドメインにアクセスしてみます。 すると IAM Identity Center ポータルに遷移して、サインインが求められます。
認証情報を入れてサインインすると、リダイレクトされて 静的サイトを表示できました。
おわりに
以上、IAM Identity Center ユーザー向けにS3静的サイトを提供してみました。
余談ですが静的サイトジェネレーターである MkDocs を入れて表示させてみました。
問題なく表示されます。 (スラッシュ / 終わりを index.html にリダイレクトするリスナールールを入れると、 ページ遷移もできました)
ガイドラインを静的サイトで構成して、 AWS利用者に向けて公開する、といった用途にも使えそうです。
以上、参考になれば幸いです。
参考
![[アップデート] AWS Verified Access で新機能「ポリシーアシスタント」が使えるようになりました。ポリシーの作成・変更時にちょっと便利になります](https://devio2023-media.developers.io/wp-content/uploads/2023/08/aws-verified-access.png)
